- web6047 - (2021/09/10(金) 現在、システム調整中のため、一部の表示がおかしいかもしれません)

web6047 2020年 6月

プログラミングやRPG(作るほう)が好きな人の日記


このホームページは毎日 夜11時にアクセスできなくなります。

朝6時半に再開されます。(世の中のネット依存対策として)

NO PC WEEK に代わる PC 使用制限のしくみ(β版)
No. (ついでに
勉強1問)
PC使用
開始時刻
予定使用時間 時間:分
(当日限度時間 時間:分)
予定終了時刻 実際終了時刻 実際使用時間 時間:分
(当日限度時間 時間:分)
オーバー理由
判定 作業内容








(1時間使用せず)
91 22:06 1:30(4:00) 23:36 23:41 1:35(4:00) RPG試作
90 18:00 1:30(4:00) 19:30 19:38 1:39(4:00) RPG試作
89 19:55 1:30(1:30) 21:25 21:35 1:40(1:30) RPG試作
88 20:40 1:30(1:30) 22:10 22:13 1:33(1:30) RPG試作
87 18:25 1:30(1:30) 19:55 20:10 1:45(1:30)
あとちょっとと思った
RPG試作
86 18:45 1:30(1:30) 20:15 20:15 1:30(1:30) RPG試作
85 21:45 1:00(2:00) 22:45 22:54 1:09(2:00) RPG試作
84 19:15 1:00(2:00) 20:15 20:18 1:03(2:00) RPG試作
83 × 21:45 1:30(4:00) 23:15 23:45 2:00(4:00)
ちょっとのつもりが
日記のカレー少女絵
82 19:00 1:30(4:00) 20:30 20:40 1:40(4:00) RPG試作
81 12:30 1:00(4:00) 13:30 13:35 1:05(4:00) RPG試作
80
21:05
1:30(4:00)
22:35
22:41
1:36(4:00)

RPG試作
79 18:50 1:00(4:00) 19:50 20:16 1:26(4:00)
時間に気づかず
RPG試作
78 13:50 1:30(4:00) 15:20 15:27 1:37(4:00) RPG試作
77 21:50 2:00(3:00) 23:50 23:56 2:00(3:00) RPG試作
76 18:00 1:00(3:00) 19:00 19:00 1:00(3:00) iTunesと画像表示の連携
75 20:20 1:30(1:30) 21:50 21:57 1:37(1:30) RPG試作








(1時間使用せず)
74 17:20 1:30(4:00) 18:50 18:58 1:38(4:00) RPG試作
73 13:00 1:30(4:00) 14:30 14:35 1:35(4:00) MS Small Basicお試し
72 23:05 0:30(2:00) 23:35 23:37 0:32(2:00) RPG試作
71 20:55 1:30(2:00) 22:25 22:25 1:30(2:00) RPG試作
70 21:30 0:30(0:30) 22:00 22:11 0:41(0:30) RPG試作
69 17:40 2:00(4:00) 19:40 19:52 2:12(4:00) RPG試作
68 14:10 2:00(4:00) 16:10 16:24
2:14(4:00)
RPG試作
67 21:50 2:00(3:00) 23:50 23:59 2:09(3:00) RPG試作
66 19:15 1:00(3:00) 20:15 20:24 1:09(3:00) gamepadAPIお試し
65 21:35 1:00(2:00) 22:35 22:37 1:02(2:00) gamepadAPIお試し
64 19:25 1:00(2:00) 20:25 20:27 1:02(2:00) RPG試作
63 21:20 1:00(1:00) 22:20 22:24 1:04(1:00) RPG試作
62 17:35 1:00(3:00) 18:35 18:45 1:10(3:00) RPG試作
61 12:50 1:00(3:00) 13:50 13:52 1:02(3:00) RPG試作
60 7:30 1:00(3:00) 8:30 8:34 1:04(3:00) RPG試作
59 22:40 1:00(2:00) 23:40 23:42 1:02(2:00) RPG試作
58 19:45 1:00(2:00) 20:45 20:52 1:07(2:00) RPG試作
57 18:00 2:00(4:00) 20:00 20:05 2:05(4:00) RPG試作
56 13:15 2:00(4:00) 15:15 15:17 2:02(4:00) RPG試作
55 14:10 2:00(4:00) 16:10 16:15 2:05(4:00) RPG試作
54 11:00 2:00(4:00) 13:00 13:05 2:05(4:00) RPG試作
53 20:10 2:00(2:00) 22:10 22:15 2:05(2:00) RPG試作
52 18:25 1:30(1:30) 19:55 20:27 2:02(1:30)
うまくいかないから
RPG試作
51 18:50 1:30(1:30) 20:20 20:30 1:40(1:30) WebWorkerお試し
50 20:50 1:30(1:30) 22:20 22:33 1:43(1:30) WebWorkerお試し
49 22:14 1時間(2時間) 23:14 23:16 1時間(2時間)
RPGイベント試作
48 17:16 1時間(2時間) 18:16 18:25 1時間(2時間) 5月扉スクリプト
47 21:15 1時間(4時間) 22:15 22:49 1.5時間(4.5時間) ドラゴンモデル(再)
46 15:10 1.5時間(4時間) 16:40 16:46 1.5時間(4時間) ドラゴンモデル(再)
45 11:40 1.5時間(4時間) 13:10 13:20 1.5時間(4時間) ドラゴンモデル(再)
44 21:20 1.5時間(1.5時間) 22:50 22:59 1.5時間(1.5時間) ドラゴンモデル(再)
43 22:25 0.5時間(0.5時間) 22:55 23:03 0.5時間(0.5時間) ドラゴンモデル(再)
42 18:20 1.5時間(1.5時間) 19:50 19:57 1.5時間(1.5時間) ドラゴンモデル(再)
41 18:40 1.5時間(1.5時間) 20:10 20:17 1.5時間(1.5時間) ドラゴンモデル(再)
40 21:10 1.5時間(1.5時間) 22:40 22:50 1.5時間(1.5時間) ドラゴンモデル(再)

※多くの人はパソコンのやりすぎやネットゲームのやりすぎには困っていると思います。参考に言うとこの表を使う前の私は 1 回の PC 使用時間がノンストップで 17 時間というときもあったし、平均で言うと 9 時間はやっていたと思います。そういう夜間を含めた長時間作業よりも、昼間の短時間作業のほうが生産性は高いと数年前から考えてきました。今はこの表の通りその理想が実現されている状態です。対象が PC ではなくネットゲームである人は、長時間で仮想世界で活躍するよりは、昼間の短時間でたしなむ程度に楽しむほうが、人生トータルで見たときにきっと昼間のあいだに誰か友達にその面白さを教えてあげるとかそういう充実した場面があると思います。夜間に長時間やっているとそういう場面の望みは少ないと思います。疲れた顔になるし生活が回らないので。

※私はパソコンの使用時間を事前に決めてネット上に公開することで、パソコンのやりすぎを防止できるかどうか試しています。

※日付は表示していません。しかし、白と灰色の色分けは、同じ色の連続で同じ日を表しています。

※「実際終了時刻」のあと、プログラミングの場合のみスッパリ終了しないで、今後のプログラミングの方針をテキストファイルに書くのは OK にしています。

※自分のホームページやプログラムを読んでいて誤字脱字を発見した際、その「修正」は訪問者にとっても管理人にとっても有益なので、「タイマーで測って10分未満。1点修正したら終了」を条件に作業してよい。また、基本的にそれを連続させないこと。

※左端に「(ついでに勉強1問)」を追加しました。遊び100%の毎日を送るときでも勉強の習慣を忘れないために、たった1問で良いので解くことにします。でも正直言うと毎回遊ぶ前に必ず1問勉強するのは心が折れそうです。でも慣れさえすれば…と思います。追記:やってみると結構効果的で役立っています。

※結果として、結構いい結果になっています。今までできなかった、炊事や掃除、散歩、早起きなどができるようになりました。ただし、「PCのプログラミングなどがうまくいかず、解決に向けて夢中になっている」ときに、「終了時間」が迫った場合、その2つに自分が「挟み撃ち」になり なかなかやめられないという状況になります。そういうときけっこうやばいです。頭の中で天使と悪魔が戦いを始めます。今のところ戦いには(おおむね)勝っていますが、「実際終了時刻」は本当は6分多いとか、そんなことを始めちゃっているので、挟み撃ちの際の対応が課題になっています。しかし多少のごまかしがあってもおおむね良い結果が出ているなら良しとしています。

…ダメかな?




2020/6/29(月)

プログラムの感動 -[program]

自分に課した制限時間内(NO PC WEEK に代わる PC 使用制限のしくみ(β版))で全力疾走してプログラムを組んで、制限時間の最後に目的のプログラムに到達すると、深い感動を覚えます。

特異な趣味だなぁと思います。

昔、私が Web系のプログラマーだった頃、同じような感じで真面目な顔して楽しそうにプログラムに取り組んでいる人がいて、はたから見ていて良い感じがしていました。自分の腕を振るって真面目に取り組んでいる人って感じが良いのかもしれません。

プログラムは全然できないけど、その職場に入ってきた人がいて、プログラムができる人がうらやましいと言っていました。

さまざまな工具(たとえです)をずらっと並べて自由に使いこなしているので、うらやましいと思うんでしょう。

うらやましいと思ってまず始めることは、「自分がやりたいプログラム」を見つけることです。

「プログラム自体がやりたいプログラム」というのも あり かもしれませんね。

入門書とかを見て、入門書の指示通りにプログラムを入力して動かすんです。楽しいんじゃないかな。


(訪問者のどんなニーズと この記事がつながるか)


2020/6/28(日)

プログラムの問題 -[program]

複数の要素に前後関係を持たせたい場合、下図のどっちにしたほうが、プログラムは見た目で分かりやすくなる?



具体的には、あるメニューはサブメニューをいくつか持っていて、サブメニューがキャンセルされるとそのサブメニューは消えて上のメニューへ戻る。というプログラムで、上記のような迷いがあります。

それだけではなくて、メニューの上にはレイヤーという概念があって、あるレイヤーが閉じられると前のレイヤーへ制御が移る、というようにしたいです。

サブメニュー2が閉じられるとサブメニュー1に戻り、サブメニュー1が閉じられるとメニューに戻る。メニューが閉じられるとレイヤー2が閉じられ、制御がレイヤー1へ移る。

上図 A, B のどちらでも同じことができるのだろうけど、どっちでもいいのではなくて、納得のいく綺麗なもので 誰にでもわかるようなものでないと いけないのだよ、明智君。最近、そういう言い回し聞かなくなったね、明智君。

誰にでもわかるように、だったら B かなぁ。


(訪問者のどんなニーズと この記事がつながるか)


カレーの問題 -[spirit]

今日の夕飯はカレーライスです。

写真のご飯をよく見ると、レトルトごはんを温めてそのままあけただけで、レトルトのケースの形がプッチンプリンしたみたいに そのままになっています。

私がカラオケボックスで働いていた時は、お客さんにフードメニューを出していて、メニューの中にカレーもありました。

カラオケボックスというのはカラオケの部屋を準備する以外に、大勢のお客さんの注文をさばく仕事もあって、注文1つ1つに時間をかけられません。

そのため、ごはんはレトルトごはんをレンジでチンして盛り付けるだけ。カレーはその頃、ガス台など火を使う料理は火事になって危険ということで、温め専用に用意した湯沸かしポットの中へレトルトのパックごと入れて温めるといったことをしていました。

お客さんに出すときは、そういう裏方の事情を さとられないようにきちんと、ごはんのケースの形をほぐして出す、という私なりの信念みたいなものがあって、アルバイトさんたちにも「ケースの形は頑張ってほぐしてくれ」と頼んでいました。それでも ほぐしきれないアルバイトさんもいて、お客さんはどう思うのか…と心配していました。

―――ところが、ある日、24hのレジャー施設へ遊びに行ったときに そのレストランで夜明け頃にカレーを注文したところ、厨房で一人で働いていた十代くらいの女の子が「ハイどーぞ」と言って、レトルトケースに入った状態のごはんとカレーを出してくれました。

つまりごはんとカレーは2つに区分けされたケースにオールインワンで入っていて、フタを点線まではがして、レンジでチンしてケースのまま出す、というものでした。

 ←こういう感じ

あっけらかんと うれしそうに出してくれたのが印象的で、まるでそれがレストランとして当たり前の常識であるかのように、その時その場では、そうなっていて、私はカルチャーショックを受けつつも普通に受け取って、普通に食べました。接客は良かったし、カレーもおいしかったです。

ケースの形を残したまま出すことがお客さんに対して失礼かと言ったらそうとはかぎらない。もしかしたら提供側の気持ち次第なのかもしれない…と考えさせられました。

それ以来、その時のことを思い出してレトルトケースの形を残してお皿に盛り付けたりしています。

「ハイどーぞ

ちなみにごはんにかかっている緑の粉はパセリ―です。これもカラオケボックスのころに覚えた技で、パセリ―をかけるだけで別の料理に変身します。見た目が変わるだけで味はほとんど変わりませんが、リッチ感が違います。カレーだけではなく、粉のレトルトのコーンスープにかけてもそうだし(下図左)、ミートソーススパゲッティにかけてもそうです。150円くらいで1か月、2か月とパセリ―・リッチ生活を楽しめるのでおススメです。パセリッチ。お店のスパイスコーナーにコショウと一緒に置いてあります(下図右)。

▼レトルトのコーンスープにパセリーを振ると変わる
▼パセリ―はスパイスコーナーに置いてある


(訪問者のどんなニーズと この記事がつながるか)


2020/6/24(水)

今日は休日

このページの最初の表、「NO PC WEEK に代わる PC 使用制限のしくみ(β版)」の右端の「作業内容」の列を見れば、日ごろから私がパソコンで何をしているか、一目瞭然ですね。

RPG試作について -[rpg]

最近やっている「RPG試作」ですが、「RPGというゲームを実現する、ごく基本的なプログラムってどんな形のプログラムか?」と思っていろいろ模索しています。人によって使うプログラミング言語はさまざまなので、特定の言語に限らず、フローチャートとか仮想言語(書類上でプログラムの流れを示すために用意されたような仮想のプログラミング言語)のレベルで、どう作るのかというのを表現したいです。


(訪問者のどんなニーズと この記事がつながるか)


2020/6/20(土)

父の日 -[season]

母の日で贈り物を送っていたので、父の日も送ることにしました。

事前に高島屋の通販でビールセット(飲み比べができる楽しいもの)を選んで当日に届けてもらうようにしていました。

それで届いたらしく電話が来て喜んでいました。

電話の話の中で、「通販」という言葉を出したら、急にその価値が下降しそうだったので、「ちょっといいとこで頼んだほうがいいかなと思って高島屋の通販にしたんだよ」と言って、価値を維持しました。昭和の時代では ”贈り物はお店のサービスカウンターで買うもの” というのが通例だったみたいで、それが通販というのは最近の時代の流れかもしれません。贈り物の価値は下げてはならないので、大丈夫だったかなと心配です。「ちょっとお店に出向いて買う」という事実も贈り物には必要なのかもしれません。今後特別な贈り物は通販ではなくお店に出向くようにしたいと思います。

デジタルでいろいろ便利になっても、人の心はそんな簡単な方法で動かせない。安易に便利にしすぎているのかなぁ。

もしかして人類はデジタルをもてあますのかな。

こういうときはデジタル。こういうときはデジタルを使わず人の手で行う。という分別を上手に行えるのだろうか。


(訪問者のどんなニーズと この記事がつながるか)


2020/6/18(木)

キーボードスタンド -[shopping]

ノートパソコンやキーボードを使っているとき、本を広げようと思っても置く場所ってありませんよね。

そこで、このようにキーボードスタンドを作りました。

浮いてるね! ノッテルネ!

下部が開いているので本が自由におけます。他にも…


▼ごはんにしたいとき

これは結構助かる!
▼パソコンを使いながら、電子回路を組むとき

これも結構助かる!


と、いろいろな場面で自由になります。

打ち込みしづらいんじゃないかと思われるかもしれませんが、そうでもないです。


各種情報

使用した木材は 38 x 89 x 910 (mm) で、ホームセンターで購入しました。

木材のカットはハンディタイプの電動ノコギリ(4000~6000円程度のもの)を使いました。

きっちり測って設計して作るつもりはなかったので、目分量で作りました。

スタンドの幅はテーブルの幅 めいっぱい に合わせました。

テーブル面からスタンドまでの空間の高さは完成後に測ったところ、 8cm ありました。これでお茶碗はぶつかりません。ただし どんぶりはたぶん入りません。

スタンド天面の角度(傾斜)は水平を 0 度として 20 度ちょっとくらいです。引っかけてるキーボードの高さ調整(下図右端)が ずりおちそうになるのでもうちょっとゆるい角度が良かったようです。

▼上から見たところ。
▼高さを取るため目分量で上方にずらして ねじ止めしました。
▼キーボードの高さ調整で引っかけます。

ねじ止めは、あらかじめ電動ドリル(4000~6000円程度のもの)でねじよりも少し細めの穴を開けてから、その穴に対してねじを入れてねじ止めします。そうしないと木材が割れたり、亀裂が入ったりしてしまいます。

電動のこぎりで木材を切り分けるときも、切り分け部分を鉛筆で線を引き、その線に沿って小さなノコギリ等で表面に溝を作って、電動のこぎりの刃が曲がって進まないようにします。

設計みたいに測ったりはしませんが、目安で定規を当てて大まかな位置決めなどは行います。


こういう家具のニーズはあると思いますが、なかなか良い製品がないので、自分で作ることを考えると思います。

でもどんな形が良いか、複雑ではなく単純に作るには…と考えるとなかなか良いアイデアが浮かびません。

今回は昔から同じようなものを2つくらい作ったことがあって、今回もちょっと考えたところ、シンプルなものができたので、皆さんのアイデアとしてどうかなと思って提案(紹介)してみました。


(訪問者のどんなニーズと この記事がつながるか)


2020/6/12(金)

今日から4連休

6/12(金) 仕事先が振り替え休日 (予定する将来の連休が振出(出勤)になる)

6/13(土) 

6/14(日)

6/15(月) 仕事先が職場の全員に有給休暇取得を推奨している日

そういうわけで4連休です。


ゲーム音楽(シンセサイザー)の雑談

雑談を4つ。

[1/4] ゲーム音楽の途中でラップとかも聴いている

私が聴いているゲーム音楽のプレイリストの中に、エミネムのラップ「lose yourself」という曲も一緒に入れていて時々聴いているんですけど、かっこいいなぁ。ほかのラップとは違って一般ウケする感じがする。

どうして私がエミネムなんて持っているのかというと、10年くらい前にカラオケで店長業務をやっていたころ、アルバイトの専門学校生の女の子が、エミネムとかスヌープドッグだとか、それらのラッパーたちの抗争などラップ音楽業界の話をいろいろ話してきて、「じゃぁちょっと聴いてみるか」と思ってエミネムのアルバム「カーテンコール」を買ったんでした。

プレステの「パラッパラッパー」(音ゲー)とか結構おもしろいんだよなぁ、ニワトリおばさんのラップとか玉ねぎ師匠のラップとか結構 ハードでしたが全クリしましたよ。またやりたい。


[2/4] ピコピコ音 vs 自然音 どっちが優れている?

私が聴いているゲーム音楽は主にシンセサイザー(ピコピコと言われる PSG や、そこから一歩進んだ FM音源)の曲が 300 曲くらいあり、最近の自然音とかオーケストラによるゲーム音楽は 2、3曲程度と少ないです。

ファミコン、メガドライブ、セガマスターシステム、PC-98/88、スーファミ、プレステなど。

文字ばかりの記事じゃ読めないんだよな…と思ってひとつ図を入れました。

写真はシンセサイザーの IC です。
こういうのが各ゲーム機の基板に はんだ付けされていて、コレに曲データを流してあげるとピコピコの音声を出力します。

ヤマハ音源IC
■YMZ285-D
■SSG音源+PCM再生機能IC

(注:ただし、この IC は多くの電子工作愛好家の方々が「使い方がわからない」と言って嘆いているようです…)


いまさらですが、世の中のゲーム事情はだいぶ変わりましたよね。

グラフィックは、ドット絵からリアルな 3D へ。

音楽は、ピコピコのシンセサイザーから自然音へ。

それでもなお、ドット絵やピコピコが愛され続けるのはきっと、その単純さのせいか ハッキリとしていてムードがダイレクトに伝わってくるからなんじゃないかなぁ、と思います。

逆に、グラフィックも音楽もリアルであるほど どうでもよくなったり疲れたり、入り込めなくなったりするんじゃないかなぁ。

例を挙げると、課長クオリティのよゐこの…誰だっけ。あの人もファミコンのゲームは(いっきだろうとなんだろうと)超燃え燃えでプレイしてたけど、スーファミの RPG となるとどこかノッテいない様子でした。グラフィックがきれいすぎてよくわからなかったんじゃないかなぁと思います。

でもそれも偏見かもしれなくて、リアルな3Dや自然音も、それを生かすか生かせないかは作り手のセンス次第なのかもしれませんね。

たとえば、Nintendo3DS の「New スーパーマリオブラザーズ2」(2012年)を最近購入して やっていますが、ドット絵というよりは 3D のポリゴンで作られているようだし、イヤホンで聴くとだいぶ音質が良く、自然音どころか曲の中に人のコーラスが入ってますよね。センス良く完成されています。このソフトに対して課長はどんな評価を出したんでしょうね。


[3/4] 燃えよゲーム音楽

私が聴いているゲーム音楽 300曲は、私が厳選した曲ばかりなので聴いているとけっこう燃えてきます。

みなさんが人のプレイリストを眺めてもあまり面白くないかもしれませんが、私が毎日聴いている その燃えてくる 300 曲あまりのプレイリストを PDF へ印刷したので掲載します↓(数曲、ポップスも入っています)

そして、厳選ではなく、ゲーム音楽全体はというと…↓

ゲーム音楽だけで 998 曲あって、全部聴くのに 1.4 日かかるですか。

コレクターやで。ゲームセンターアラシやで! (あれは音楽の話じゃない)

あと2曲で1000曲の大台に!


[4/4] PSG 音源と SSG 音源のちがい

PSG って Programable Sound Generator の略です。

PSG に似た言葉で、SSG音源というものがあって、同じような音をしています。

2つの違いって何だろうと思って調べてみました。

そしたら SSG とは「FM音源によるPSG互換機能」で、Software-controlled Sound Generator の略だそうです。

昔からの謎が解けました。


以上シンセサイザーについての雑談でした。


(訪問者のどんなニーズと この記事がつながるか)


2020/6/9(火)

JavaScript の WebWorker -[javascript]

3DCG のドラゴンを表示している viewer.html について、JavaScript の WebWorker という機能を用いて高速化できないかと試してみました。

WebWorker とはメインの JavaScript とは別に裏で動いて計算をしてくれる JavaScript です。

WebWorker に 3DCG の3次元計算の部分だけを行ってもらい、計算が終わったらメインの JavaScript が計算結果を受け取り、その計算結果をもとに描画を行います。

計算と描画をうまく同時進行(並列)させれば高速化になると思ったんです。


時間がないので結果だけ言うと、なんと WebWorker を使ったほうが、使わないものよりも余計に時間がかかってしまいました。

どうも WebWorker は表裏のあいだのデータの通信に時間がかかるみたいです。

メインの JavaScript と WebWorker は互いにオブジェクトを参照できず、オブジェクトを平文か何かのデータに直して(シリアライズという言葉を使っている)、送受信しています。

確認はしていませんが、きっとそこで時間がかかっているんだと思います。なら、通信させるデータを限定して(減量して)…とも思いましたが 3DCG のデータで削れるものはないなぁ…と思いました。

以下は私が行った簡易的なベンチマークです。


WebWorker を使わない場合 右端の太字の calc の部分に注目。3~12 ms で3次元計算が終わっている。(左の青い表示は時間を出力したものです。気にしないでください)

そのベンチマークプログラムを実行

10フレーム(10回描画)実行して止まります。CTRL+SHIFT+J を押してコンソールを開くと結果が出力されています。(上図画像の青い表示部分)

出力の右のほうの2つの数字(#と+のあいだの2つの数字)はそれぞれ、その処理を実行した時刻の秒とミリ秒です。

そのミリ秒の差分(calc.end - calc.start など)を上図画像の右端の太字部分に表示しています。


WebWorkerの場合 右端の太字の calc を見ると、同じ計算なのに時間がかかっている。58~80ms。通信に 50ms くらい余分に時間(オーバーヘッド)がかかっている? draw はどちらも同じくらいです。

そのベンチマークプログラムを実行

worker.js の内容


きっと WebWorker はゲームみたいなリアルタイムで何かをする用途には向いていないんです。科学技術計算向きなんです。

そんな記述をどこかで読んだ覚えがあります。( それを先に思いだせよ=3 )

残念でした。orz


(訪問者のどんなニーズと この記事がつながるか)


2020/6/7(日)

このホームページのアドレス変更について

このホームページのアドレスは、来る 2020/7/1 に web6047.sakura.ne.jp に変更されます。


web6047 の新しいアドレスは申請済みで、データ(コンテンツ)のコピーも済んでいます。

現在は、homepage6047(旧)、web6047(新) 両方にアクセス可能な状態です。

ただし、homepage6047(旧) の更新は停止し、web6047(新) のほうだけを更新します。

2020/6/30 には homepage6047(旧)へのアクセスはできなくなります。


みなさま、お手数ですがブックマークを作り直してください。

新しいアドレス https://web6047.sakura.ne.jp/


さようなら homepage6047、こんにちは web6047。


アドレス移行 ロードマップ(計画表)
日付 実施内容 状況
2020/6/1(月) web6047 新アドレス 申請
2020/6/7(日) web6047 新アドレス アクセス可能
 ~ homepage6047、web6047 両方にアクセス可能な期間(1か月間) 現在
2020/6/30(火) homepage6047 旧アドレス 終了 予定
2020/7/1(月) web6047 新アドレス 移行完了 予定


余談

なお、2つのアドレスを1か月間併用することにかかるコストは 500円 くらいです。

年間契約のホームページ領域を1か月間だけ2つ持っている状態です。

1年あたり 5000円 程度の契約なので、単純に10(≒12か月)で割って 500円です。

下図の赤い部分の月(今月)が 500円余計にかかっています。

homepage6047 の契約 5000円 7 8 9 10 11 12 1 2 3 4 5 6










web6047 の契約 5000円










6 7 8 9 10 11 12 1 2 3 4 5

旧アドレスを 3か月間 もたせたいときは赤い部分が 3ヶ月間になるように早めに新しい契約を開始すれば良いということです。

その時は 1500円くらいの費用が掛かるということですね。


一時的にホームページ領域を2つ持つ、というとお金がかかる気がしますが、案外安く済むんですね。


(訪問者のどんなニーズと この記事がつながるか)


2020/6/6(土)

ドラゴンモデル(再) 5 -[3dcgprogram]

最終的なビューワーです。

タッチ操作やマウス操作に対応しています。

ドラゴンの色をランダムに変えられます。


(訪問者のどんなニーズと この記事がつながるか)


2020/6/4(木)

ドラゴンモデル(再) 4 -[3dcgprogram]

色分けで、ツメの白がちょっとおかしかったのが直っています(原因は不明のまま)。

口の中を赤く塗り、牙を付けました。

その他不正なポリゴンを直しました。

この画像リンクをクリックすると JavaScript で3D表示します。

だんだんドラゴンらしくなってきました。


(訪問者のどんなニーズと この記事がつながるか)


2020/6/2(火)

ドラゴンモデル(再) 3 -[3dcgprogram]

ポリゴンの不備を直して、一部色分けしたバージョンです。

今度は色分けで、ツメの白がちょっとおかしいですが…。

下の画像リンクをクリックすると新しいウィンドウで JavaScript を実行します。

このドラゴン(3DCGソフトで作ったモデルを JavaScript で表示)を作っている目的は、

の3点です。


(訪問者のどんなニーズと この記事がつながるか)


2020/6/1(月)

新しいアドレス

今月は新しいURLを申請予定です。


(訪問者のどんなニーズと この記事がつながるか)



webappsrcの確認

1. %%com.webapp.src:/webappsrccheck.html%%
と記述した場合

webapps/src/default.cssのスタイル指定が効く
<!DOCTYPE html><!--ESCAPEPROCESS-->

<head>

<script>

function onloadx() {

//一般関数

console.log( "文字列" );

}

function Class1() {

//クラス

console.log( "文字列" );

}

Class1.prototype.method1 = function() {

//メソッド

console.log( "文字列" );

}

</script>

</head>

<body onload="onloadx();" style="">

Hello world!<BR>

</body>

</html>



2. <code>
%%com.webapp.src:/webappsrccheck.html%%
</code>
と記述した場合

このファイルのcodeのスタイル指定が効く
<!DOCTYPE html><!--ESCAPEPROCESS-->

<head>

<script>

function onloadx() {

//一般関数

console.log( "文字列" );

}

function Class1() {

//クラス

console.log( "文字列" );

}

Class1.prototype.method1 = function() {

//メソッド

console.log( "文字列" );

}

</script>

</head>

<body onload="onloadx();" style="">

Hello world!<BR>

</body>

</html>



3.
%%com.webapp.src:/webappsrccheck2.html,/webappsrccheck.html%%
と記述した場合

webapps/src/default.cssのスタイル指定が効く
<!DOCTYPE html><!--ESCAPEPROCESS-->

<head>

<script>

function onloadx() {

//一般関数 コメント変更

console.log( "文字列変更" );

行追加

}

function Class1() {

//クラス コメント変更

console.log( "文字列変更" );

行追加

}

Class1.prototype.method1 = function() {

//メソッド コメント変更

console.log( "文字列変更" );

行追加

}

</script>

</head>

<body onload="onloadx();文字列変更" style="">

Hello world!<BR>

HTML追加

</body>

</html>



4. <code>
%%com.webapp.src:/webappsrccheck2.html,/webappsrccheck.html%%</code>
と記述した場合

このファイルのcodeのスタイル指定が効く
<!DOCTYPE html><!--ESCAPEPROCESS-->

<head>

<script>

function onloadx() {

//一般関数 コメント変更

console.log( "文字列変更" );

行追加

}

function Class1() {

//クラス コメント変更

console.log( "文字列変更" );

行追加

}

Class1.prototype.method1 = function() {

//メソッド コメント変更

console.log( "文字列変更" );

行追加

}

</script>

</head>

<body onload="onloadx();文字列変更" style="">

Hello world!<BR>

HTML追加

</body>

</html>



5. リンクで
src?webappsrccheck.html
と記述した場合

webapps/src/default.cssのスタイル指定が効く
開く

6. リンクで
src?webappsrccheck2.html,webappsrccheck.html
と記述した場合

webapps/src/default.cssのスタイル指定が効く
開く